Clustered R&R?

HCL Notes/Domino 8.5 Forum (includes Notes Traveler)

Subject:

Clustered R&R?

There are a couple possibilities for how your room got double booked. So I will cover them all and you can see which best fits your case:

1: Your R&R server is clustered, possibly over a WAN. If the Domino cluster gets 'split' with both servers still up then both servers will think the other went down and both servers will try to process requests as they arrive. If requests get delivered to the different servers that conflict then it is possible that Server1 will accept a request that conflicts with something booked on Server2 which Server1 does not know about.

If you have the Accept notices for UserA and UserC then you can check the RouteServers values or the $CSTrack items to see where the responses were created. For this case you would see Server1 listed on one notes items and Server2 listed in the others.

You can use the tell rnrmgr whoowns YOUR_RnR_DB_NAME_GOES_HERE.nsf console command on both servers to see which servers think they are in control. In cases like this you will get Server 1 saying it owns the dB while Server 2 says it does. Fixing this is pretty straight forward: restart the RnRMgr task of the server that should NOT be in control (e.g. the one with the OLDEST timestamp). This does not resolve the double bookings but it will stop future ones.

We do not really recommend you cluster across a WAN due to the high latency involved and the increased risk of getting a 'split cluster'. If you have done this then I recommend you read the TechNote we have on WAN clustering and what to keep an eye on. (Sorry, I dont have the # handy; I am on vacation and not at my desk).

L2 has a tool which can help you find double bookings that were created so you can notify the affected users and let them resolve the conflict (or you can act on them manually if you are the dB Admin).

2: There is a problem in the busytime dB on the server: you have multiple records for the same room or you have replication conflicts.

The multiple record case is a rare and very intermittent one. In this case NSF has forgotten about the existing busytime record and so when RnRMgr asks NSF to return the current record so it can add a new reservation to it, it fails to return the existing doc. So RnRMgr assumes that this is the first request for the room and tells NSF to create a new record and put the new reservation on it. This means that all other prior bookings for the room get 'forgotten'. If this is what you see in the busytime dB then you will need to follow the published TechNote on rebuilding busytime (sorry, I dont have that # handy) If you see this happening a lot then please consider opening a ticket with Support so we can work with you to try and gather some data about what may be causing it.

The replication conflicts case is a relatively new issue for busytime. The root cause is not clear. If you see this then please consider opening a ticket with Support so we can investigate it with you. As with the multiple doc case, the resolution is to rebuild the busytime dB.

As I mentioned earlier, you can contact Support to get a tool which will help you find any duplicate bookings in your R&R dB so that you can notify your users before their meetings happen.

Bruce
IBM